COMMENT ⊗   VALID 00003 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	∂27-Sep-86  1232	willc%tekchips.tek.csnet@CSNET-RELAY.ARPA 	Link tables 
C00006 00003	∂27-Sep-86  1413	FAHLMAN@C.CS.CMU.EDU 	Link tables  
C00012 ENDMK
C⊗;
∂27-Sep-86  1232	willc%tekchips.tek.csnet@CSNET-RELAY.ARPA 	Link tables 
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 27 Sep 86  12:32:01 PDT
Received: from tektronix by csnet-relay.csnet id aj02327; 26 Sep 86 7:05 EDT
Received: by tektronix.TEK (5.31/6.16)
	id AA20806; Thu, 25 Sep 86 18:19:03 PDT
Received: by tekchips.TEK (5.31/6.16)
	id AA21969; Thu, 25 Sep 86 18:19:51 PDT
Message-Id: <8609260119.AA21969@tekchips.TEK>
To: Fahlman@C.CS.CMU.EDU
Cc: rpg@SU-AI.ARPA
Subject: Link tables
Date: 25 Sep 86 18:08:56 PDT (Thu)
From: willc%tekchips.tek.csnet@CSNET-RELAY.ARPA

Even if link tables really are so important to efficiency that a dialect
of Lisp should be designed with an eye toward their use, there are many
ways to do that short of splitting the function and value environments.
I don't favor the proposals below, but I hope they show that the issue of
function cells can be separated from link tables and other efficiency
issues.  By the way, Norman Adams suggests that Jonathan Rees would be
the person best qualified to estimate how much efficiency is lost or
gained on the VAX by using link tables.

In a CL without function cells, DEFUN could be given a semantics
intermediate between DEFPARAMETER and DEFCONSTANT:  It would be an
error to re-define a variable defined using DEFUN except through
another DEFUN or an UNDEFUN (where UNDEFUN is parallel to UNDEFCONSTANT
or whatever).  If you liked, you could also keep SYMBOL-FUNCTION for
the purpose of allowing (SETF (SYMBOL-FUNCTION ...) ...) on variables
defined by DEFUN.

More cleanly, (DEFUN FOO (...) ...) could be equivalent to
(PROGN (UNDEFCONSTANT FOO) (DEFCONSTANT FOO (LAMBDA (...) ...)))
modulo the implicit BLOCK and any other hair I've missed.
In defense of the Franz compiler's compilation of self-tail-recursion
as a backward branch, John Foderaro has argued that CLtL permits a
similar interpretation of DEFUN even now (but for the function cell
instead of the value cell) and that if his interpretation is incorrect
then the semantics of CL should be changed.

I hope these examples suggest that legitimate concerns about efficiency
can be addressed by careful language design.

Peace, Will

∂27-Sep-86  1413	FAHLMAN@C.CS.CMU.EDU 	Link tables  
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 27 Sep 86  14:13:42 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 27 Sep 86 17:12:58-EDT
Date: Sat, 27 Sep 1986  17:12 EDT
Message-ID: <FAHLMAN.12242356529.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   willc%tekchips.tek.csnet@RELAY.CS.NET
Cc:   rpg@SU-AI.ARPA
Subject: Link tables
In-reply-to: Msg of 25 Sep 1986  21:08-EDT from willc%tekchips.tek.csnet at CSNET-RELAY.ARPA


Will,

Making DEFUN into some kind of DEFCONSTANT is a clever idea, but it
strikes me as being even more awkward than having separate function
cells.  You'd never know what functions it was safe to rebind without
examining the place where the function was created (or checking for
constantp at runtime).  Sounds like a pain.  I'd rather keep it simple
and take a hit in performance if we can make it a very small hit.

Dave McDonald did the link-table hackery for both Vaxlisp and for the
IBM RT (CMU's version, not Lucid's).  He will be spending some time over
the next week or two trying out various ideas for how to handle a merged
namespace in such a system and getting good estimates for what each
possible mechanism would cost in performance.  I think we can get it
down to one extra memory reference and test for every SETQ of a dynamic
variable, plus more overhead if this turns out to be a symbol that
SOMEONE uses in functional position, but nothing extra on a typical call
to a dynamically bound function.  We can actually bugger a version of
our Lisp to add the extra cycles to such SETQ's and then see what the
performance cost is on an assortment of typical code.

If we can get the extra cost down under 10%, then I think reduced
performance ceases to be a politically potent argument, but if it's much
higher than that I think that a lot of companies (e.g. DEC) will dig in
their heels a lot deeper.  It's not a question of whether one should
design a language around a single efficiency hack; rather, it is a
question of whether we can ask companies to ask their customers to
accept degraded performance and a significant conversion effort just to
make peace with a handful of disgruntled European academics.  Purely
aesthetic arguments in favor of the merge will carry little weight with
these guys.  They have been using Common Lisp and not Scheme, and to
people with that background a separate namespace looks like a good way
to avoid needless errors, not like an evil wart.  If we just have to
sell the conversion effort and not reduced performance, that should be
easier.

Another political problem is everyone's fear that this is just the first
step in a wholesale upheaval of the language.  Someone -- you or Wegman,
I think -- said to Gary Brown that this was just the first step in
merging a lot of other name spaces.  He spent the rest of the day
worrying not about this one change, but about letting the "radical
change" genie out of the bottle.  I'm worried about that too, truth to
tell.  I think Gary Brown will be a good barometer of whether this
change is going to go over.  DEC has probably got more customer-written
code running on his Common Lisp than anyone else, and Gary's very
worried about screwing these people with a big change.

Peace (if it doesn't cost too much),
Scott